Description

The main purpose of this PR is modify the method UserHelper.GetUserContext() to populate the property UserContext.SocialSecurityNumber.

However, I found the flow of that method to be a bit hard to follow, which is the reason for the refactoring. And because those changes potentially modifies the logic of the method, I added a test.

Investigation needed?

I disagreed with the original logic for assignment of UserProfile.Party, so I changed it. At least with our test data, UserProfile.PartyId was not a good indicator to tell if UserProfile.Party contained valid information. The check now inspects UserProfile.Party?.PartyId instead.

If someone actually wants the original value, this is stored in UserProfile.UserParty anyway.

As for whether this impacts existing usage, it would be nice to get a second pair of eyes on the situation. Comparing app-lib-dotnet test data with app-localtest (for instance 1337.json), it appears that the change is beneficial to incomplete data sets (app-lib-dotnet, empty party definition) and will not affect behaviour for complete data sets (app-localtest).

After some back and forth on Slack, we have decided to leave the original Party assignment logic intact. Too many unknowns associated with this modification.

Motivation

A question was recently asked about limiting app access to a list of known national identity numbers (social security numbers): https://digdir.slack.com/archives/C079ZFUSFMW/p1732624713911909

The general recommendation was to solve this in the app code as opposed to XACML. Getting hold of the information seemed easiest with the help of UserHelper, but for some reason this did not populate the SSN field.

Another baffling question is why the national identity number is part of the Party definition and not, say, UserProfile. But I'm sure that makes sense to someone else.

Verification

• Your code builds clean without any errors or warnings
• Manual testing done (required)
• Relevant automated test added (if you find this hard, leave it and we'll help out)
• All tests run green

Documentation

• User documentation is updated with a separate linked PR in altinn-studio-docs. (if applicable)